feat(cluster): customisable context path #565
Conversation
Birkbjo
force-pushed
the
feat/cluster-context-path
branch
2 times, most recently
from
3ae135a to
8776455
Compare
Birkbjo
force-pushed
the
feat/cluster-context-path
branch
2 times, most recently
from
d3d2f29 to
17c6ae1
Compare
Birkbjo
force-pushed
the
feat/cluster-context-path
branch
from
17c6ae1 to
cf461d7
Compare
Birkbjo
changed the title
| const anyCustomContext = clusters.some( | ||
| cluster => cluster.contextPath !== '' | ||
| ) |
There was a problem hiding this comment.
Should we just always show the context, even if none are custom?
There was a problem hiding this comment.
We could. The idea was that this is most likely not relevant to most users. I think very few are actually using this context-path, and it might be confusing if you don't know what it does?
There was a problem hiding this comment.
I could go either way here... I also think it would be confusing if d2 cluster list sometimes renders in a different format if you happen to have a custom context on one cluster you're running. It would make any kind of parsing of the output difficult as well, though we're not exactly well setup for that as it is
| cluster.dhis2Version, | ||
| cluster.dbVersion, | ||
| formatStatus(status), | ||
| ].concat(anyCustomContext ? cluster.contextPath : []) |
There was a problem hiding this comment.
Maybe cluster.contextPath || '/' ?
There was a problem hiding this comment.
If you think we should show this regardless of any set custom-context, I agree, we should probably do that.
Or do you mean we should show '/' instead of an empty cell for non-custom contexts?
There was a problem hiding this comment.
I mean we should show / instead of an empty cell for non-custom contexts, since that's the path that they can use to access the instance
ghost
left a comment
ghost
left a comment
There was a problem hiding this comment.
I'll defer to Austin's review on this. I'm not super familiar with this bit of functionality as a user, changes look good to me 👍️
Previously the
--customContextoption for theup-command was just a boolean, and it used thecluster namefor thecontextPathwhen this was set. I think it should be possible to set this independently of thecluster name, as it's very useful if you would want additional levels, eg./dhis2/dev. This is somewhat related to CLI-75, since having a cluster with a path-delimeter (/), results in very buggy behavior.I've tried to implement this in a non-breaking way. Eg. we still support using a flag
-c, and we will then use thecluster name.